Serial No, 10/520,831 
Atty. Docket No. CYBS58S9 

REMARKS 

Rt ling i ira raph \ of the Office Action, the present amendment cancels reference 
numeral 633 from the specification. Reference numeral 406 is indeed present in Fig. 4 and has 
been added to the specification. 

Regarding paragraph 5, reference numbers 200, 214, 236, 316, 604-618, 622-624, 700, 712- 
720, 1034, 1036, 1100 and 1 120 have been added to the specification. Reference number 1052 is 
discussed in the first full paragraph of page 32 of the specification. 

Regarding paragraph 6, the first use of each of the acronyms FAT. BIOS, ROM, PC, SCSI , 
FAT2, RAM, FAT 16, FAT32 and NTFS has been spelled out. No instances of "QNK" were 
found. 

No new matter has been added. 

Each of claims 28, 30-36, 41-43, 82, 84 and 95-100 has either been canceled or amended so 
as not to include any trademarks or trade names. Reconsideration and withdrawal of the 35 USC 
§1 1 2(2) rejections are respectfully requested. 

Claims 25-27, 29, 80-81 and 83 were rejected as being unpatentable over Helbig in view of 
England. Reconsideration and withdrawal of these rejections are respectfully requested. 

jielbjg t't at. 

On page 7 of die outstanding Office Action, the Office states that H elbig discloses: 
providing &tt^ instfttiirm* £rti$t@«J vynic^son <lrfwr m im gaming macftlm>, 
tts^ trusts ¥mWm$Mm imin§ imtepemkmt of tti# $y»t&»* (col 8, 

S?#2, (ftgctosos a trusted ®pmm* m^m^m^Wm opmsmg *>*v ^ 

However, Helbig et ai. do not teach any such trusted verification driver that is independent 
of the operating system, or atty step of providing and installing such. In fact, Helbig et ai. 
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specifically teach that the "trusted operator' that the Office analogizes to the claimed "trusted 

verification driver" (and its interrace) in fa< runs imder t) > 1 } 1 , astern in 

this case the Disk operating System, or DOS: 



To enable a trusted operator (TO) to specify which components of 
the SEPB's firmware and the PC's firmware and which tiles stored on one 
of the PC's disks will be projected (and at which step each protected 
component will he verified), 3 Trusted Operator Interface Program is 
provided with the SEPB. The Trusted Operator Interface Program, which 
runs muler DOS on the PC and wilt, when executed, provide the trusted 
' j u,>'i t M)ih a 'iu. i.'iP an i mm'str- to ks.^n. i U >,» > h ht.n nutt',n Is i_s 
;B10S. intcmipt tabic, DOS , a«jne\ec. j.;aU ,co»tl!i.s% s, etc.) are to h e signed 
with a Digital Signature (or some equivalent .modification code) 
and when (at which of three steps indicated below) those signatures are to 
he verified . {U nderlining added for emphasis) 



and 



To provide a convenient method for a system administrator 10 
request that the SEPB Sign a file, the Trusted Opera tor Program was 
developed to execute under DOS after ail of the set-Hp steps have been 
pt . foi m< d. i In frust *<! Opti.iiift Program provides an interface to the 
Irusled operator to determine which of nine poN\ible operations the (rusted 
operator wishes the. SEPB to perform. After this information is entered (he 
Trusted Operator Interface Program pots the data for the operation into 
known locations in the PC's hard disk and prepares a message in the 
standard format for the SEPB. The Trusted Operator Interface Program 
then calls the SEPB BIOS Extension program. The BIOS Extension 
program requests that the SEPB MVK-80 subsystem read the data from 
the PC's RAM and make it available to the SEPB I486 subsystem. The 
hidden parts of the SEPB BIOS Extension program and the private I486 
and MYK-80 SEPB firmware then direct (be SEPB through the 
appropriate steps to perform the requested operation. {Underlining added 
for emphasis) 



The Trusted Operator, therefore, cannot both "developed to execute under DOS" and be 
independent thereof; as urged by the Office. Quite simply, the Trusted Operator allows a system 
administrator, via the Trusted Operator Interface, to designate which files the SEPB is to digitally 
sign. The SEPB is the "Security Enhanced Processor Board" and "consists of a dual 
microprocessor arrangement of an Intel I486 CPU 24 and a RISC coprocessor MYK-80, I0 f 
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programmed as a security coprocessor. The MYK-80 is a special purpose combination of an 
ARM6 RISC microprocessor, some amount of ROM to store the firmware that composes the 
routines, and other logic as needed to support the MYK-80 and external operations." Thus 
Heibig et al.'s system runs via a Trusted Operator that runs under the operating system to 
designate those files that are to be digitally signed by the security daughter board, the SEPB. 

It is respectfully submitted that nowhere does Helbig teach or suggest that the Trusted 
Operator is ' independent of the operating system", as required by the claims. 

England et a!. 

It is noted that England is relied on for its teaching of "downloading at least one software 
module into the gaming machine; and a downloaded software module" (Office Action, Page 7). 
It is also noted that the only mention of "game" in England refers to input devices (See Column 
6, lines 38-55). There are no mentions of "gaming machines" in England et ai. 

The England et ai. reference teaches digital rights management operating systems 
(DRMOS). England et al teach that the DRMOS is configured to "check itself by loading a first 
layer of the Operating Systems (the boot loader, which loads a boot, block of the OS), which then 
checks each of the remaining components of the OS to determine whether they have been signed 
by a trusted source: 

s , SS \ „ , U ( iff ) 1 

'ti!u. * f . t 1 and check* _ u •> (by using a 

. k S \ 1 v. V ! . 15 ,1 IK !•»(!' 11 t t > 111 

H ' v '! n u h 

Hils proceeds, hex < 1 t > i) device 

t i ! f !l i t ISlC 1 - , t ! 1 M 

This process is further detailed in England et al. at Column 1 1, beginning at line 39: 
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Shortly after a computer is turned oo or h reset, a sm^i , 

mi) nu h iwd^r k ! s i \<m u r p.tf 

,M ! it v i us v ' iU\ m ( 

ddvers and odu. ->d,.w e eo ; ;; s oosx:nk, > ^ fot Sr. 

o^uantig 1 . K- \iSvi !!k ^nlsH of <s 

K ^ 1 - s J ih t v \ < y-. s tp th*. 

ideamv of the opetsting sywesn. 

S iDKVt's 1 ! - , uf 

block mi.S t loaded - i \ *s s i- i to;sUak So die 1 1 > i 
i&eai.s described here is;, ad components ate somcd by a 
'.Uf^ed a :0 piovuied Oils! 4 i.sjiis i:'.i;i..rt j o :'!!:- 

Vi . ii d> - , I - . 1 - ! i„v 

certi&sic i:s described below is; eosdpsnedon wish FIG. <•* 
S <. ' o ; k- i \ s ' a t ! , it i 

KM < > J , „ i v W I ' _ M I <. , e 1 w 

tH \n dd5> tU „ > > i i ) no; l\v , t su - 

.someone ;itietnp;ing. to citaimvcnt the i»:>? process and the 
1 \*v>t ; 

»- ■" >. t ( . 30* ■ \ - ^ " ^ t >,edsd *or h 
i cte s sigtsanue) s he a tie t nasi be k 
ids -M'M i . >\i ii'. s m ti iv- > k K 

kkntiiy - DRMOS v -.omptetkm of the boot prooess 

According to England et al., the DRMOS is configured to prevent untrusted access to 
DRM-secured data and to "renounce" its once trusted identity (stored in an interna! CPU register ) if 
caused to load an untrusted software component, as taught at Col 1 .1 , line 67 to Col. 12, line 7: 



the toot process, if die device requires the ioadiag of m 
i n - > d <. i _ s, < s v * A j> ev, ipk-tes. a 
piug-,s«d-p]a\ DRiMOs. must diui un . - 

den.lt ! > 1 I'i^s 

.; s ^ *>2 ~< < 5 <- S ) ! 1 1 f 

ton it t s ( 

based oft s v.s , < ) ' \ f t n w *. 

fron; the user of the computer. 

England et al. teach various methods for detennining whether an application can he trusted, 
and all such methods appear to rely on the DRMOS checking the signature of the software 
component against a list of trusted providers (see Col 13, lines 19-35), by maintaining a boot log 
(see Col. 13, beginning at line 36) or by manipulating cryptographic key pairs (see Col 13, 
beginning at line 60) and the like. 
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Much like the Helbig et al. reference, England et al. do not. teach or suggest providing or 
installing a trusted verification drivet thai is »u ( >n.t ' of tl 1 pe ating ,1 s - and using the 
trusted verification driver to perform a verification of the operating system and to check to code 
signature of downloaded software modules or components, as apparently acknowledged by the 
Office since it withdrew its previous §§ ! 02/1 03 rejections over England and added the Helbig et al. 
reference to the outstanding §1 03( a) rejection. As noted in an earlier response, in England et al, 
the verification of the OS is performed.,, by she OS itself (Tl and not by a trusted verification driver 
that is independent of the operating system. The claimed methods and gaming machines of claims 
24 and 80, therefore, are clearly antithetical to Beibig et alls 'Trusted Operator" model, that 
operates under the control of the DOS and also clearly antithetical to the OS-centric DRMOS 
model espoused by England et al, in which the OS checks itself. 

The Helbig et al and England et a>. combination 

The applied combination of references does not teach or suggest the claimed limitation ... 

providing ami installing a trusted verification driver in the gaming 
machine, the trusted verification driver being independent of the operating 
system; 

... as both references teach OS-centric security, wherein a Trusted Operator executing 
under DOS (Helbig et al) or the operating system (DRMOS ) itself carries out the security- 
checks {England et al.}. 

The applied combination fails to teach or to suggest a trusted verification driver that is 
independent le une as claimed 

herein, hi fact, the applied combination unambiguously teaches away from such a claimed step, 
as both teach that the entity that carries out the security measures is either a program that 
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operates under the operating system (DOS, Helbig et al.'s case), or is the operating system itself 
(in England et al.'s case). 

That being established, the following claimed steps cannot be considered to be either 
taught or suggested by the applied combination: 

performing a verification of components of the operating system 
against a trusted reference using the trusted verification driver and 
preventing further operation of the gaming machine when the verification 
of the components of f he operating system fails; 



checking a code signature of at ieast one downloaded software 
module, using the trusted verification driver- and 

authorizing execution of the downloaded software module in the 
gaming machine only if rite downloaded software module is successfully 
verified by the trusted verification driver 

This is because none of these steps are possible without the provision and installation of a 
trusted verification dri ver that is independent of the operating system. 

That England teaches download ing content and, therefore, downloaded content, is not 
believed to remedy the fundamental shortcomings of the primary reference relied upon in the 
outstanding Office Action. 

Claim 80 includes recitations that are similar to those of independent claim 24, and the 
arguments above are equally applicable thereto. For brevity's sake and rather than repeating them 
here, the remarks above are incorporated herein by reference, as if repeated here in full. 

It is, therefore, respectfully submitted that the 35 USC § 103(a) rejections of the claims are 
in error and should be withdrawn. The same is, therefore, respectfully requested. 

Kindly note that ali of the changes to tire claims are related to the perceived 112(2) 
trademark and trade name issue and not to any art-related rejection. Therefore, any consideration 
that mas be required is not belies ed to be such as could be reasonably characterized as being 
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"undue". Therefore, it is respectfully submitted that the present amendment is properly alterable 
after final rejection . 

If any unresolved issues remain, the Examiner is respectfully invited to contact the 
undersigned attorney of record at the telephone number indicated below, and whatever is required 
will be done at once. 



YOUNG LAW FIRM, P.O. 
4370 Alpine Rd., Ste. 106 
Portola Valley, CA 94028 
Teh: (650)851-7210 
Fax: (650)851-7232 



Respectfully submitted. 





Alan W. Young 
Attorney for Applicants 
Registration No. 37,970 
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